Technical Field
This disclosure relates generally to web application security and in particular to a method and system for dynamic web session clean-up session using cookies that have been augmented to include sign-off resource URLs.
Background of the Related Art
When clients authenticate with a remote application, a session for that client is created on the web server. These sessions remain active until the client requests their destruction, which typically requires manual user intervention. Typically, there exists no standardized method to clean up sessions on remote servers without a static configuration that can map the session identity (usually contained within an HTTP cookie) to a sign-off resource for the session. HTTP cookies (see IETF RFC 2109) provide a way of managing sessions and state between web browsers and web servers using the HTTP protocol.
It is known in the prior art to associate a session cookie to a sign-off resource via a manually-configured static configuration. One such approach is described in U.S. Publication No. 2007/0039043. A weakness of this approach is the requirement for manual configuration and dependence on a third party application or database to manage the sign-off operations. Further, the described solution is not portable, and it cannot be extended automatically because only a list of statically-configured URLs can be invoked in the sign-off process until a new mapping of cookie-to-sign-off resource is manually added to the configuration.
It is also known in the prior to provide so-called Web portals, which are web-based mechanisms that centralize access to information, applications, and services for employees, customers, or partners. A Web portal delivers a consolidated view that lets users access electronic resources of the organization using a standard technology (a web browser), simply and efficiently. Within a Web portal or like environment, typically a proxy or web server acts as a front-end “point of contact” to a set of back-end applications or application components. In this type of environment, it is desirable that the mechanism used to provide authentication and session management at the web portal layer should also provide these functions for any back-end applications that are included in a consolidated view.
In this type of environment, approaches to session management typically have each back end application or application component requiring its own session state management, and each such application or component may implement its own session management technique. Where an end user is accessing multiple applications within a single enterprise, his or her browser ends up managing independent session management items (often as many as a different item per application). Typically, in this environment, these items are HTTP cookies, as the behavior of such cookies (although not intended for session management) provides reasonable session management.
When an authenticating reverse proxy is used to enable single sign-on (SSO) to multiple backend applications running, for example, on a web server, cookies from the backend applications are typically permitted to flow back to the web browser. When a user logs out of the reverse proxy, however, his or her existing session with the backend server can remain in the web browser's session cache, sometimes called a cookie jar. If a different user then authenticates to the reverse proxy using the same web browser, it is possible that the previous user's sessions in the backend proxied application could be used as opposed to a new session for the new user.
One solution to this problem is to embed script(s) within the logoff page of the reverse proxy to clear any cookies for the proxied applications. One of the drawbacks of this approach is that new scripts have to be added for each proxied application matching all of the cookies for this particular proxied web server. This becomes a manual process for a system administrator. Moreover, depending on the type of proxying method used and how the cookie is stored in the web browser's cookie jar, these cookies may not be able to be deleted easily. This approach can also require modifications to the proxied server's log off page, which can be quite intrusive. Further, this approach does not address the situation where the logoff is not instigated from the browser (e.g., when the user session within a reverse proxy simply times-out).
Other existing solutions include storing cookies within the cookie jar in the proxy but never sending them to the client browser. The cookies are then expired within the cookie jar on logout to provide single sign-off from backend servers. A limitation of this approach, however, is that the cookies are destroyed by the proxy when the session is terminated, but this does not terminate any corresponding sessions in the backend servers. Further, at times cookies are required in the browser for the web application to operate correctly. This approach also is undesirable in that it does not allow cookies to flow back to the web browser during the user session.